Computer programs (applications) can be very complex. Such applications might perform calculations needed for financial transactions. For example, financial applications can facilitate the buying or selling of business or financial instruments such as derivatives. The complexity involves the number and type of calculations performed by the application, the large volume of data on which the application bases those calculations and the computed data representing the results of the application's computations. Software developers generally write these applications in a high level computer programming language. Object Oriented languages, such as Sun Microsystems® Java (JAVA) and its various versions as Sun Microsystems® J2EE (J2EE the “enterprise edition”) are particularly well suited for very large complex applications.
The data that represents the inputs and outputs of the application can be voluminous. And, in large companies and financial institutions, it is likely that the data is shared by several applications. In such large and complex systems, the data representing all of the information needed by the application (inputs) and processed information (outputs) is generally stored on one or more databases that are semiautonomous of the application, i.e. the application does not directly read and write information to the databases. It communicates with the database through a database management program. Sybase, Inc.® Sybase (SYBASE), Microsoft® SQL Server (SQL SERVER) and Oracle Corporation® Oracle (ORACLE) are exemplary of such commercial database products.
One aspect of database programs is that the data is stored, read, and written in the form of tables. Database data is typically grouped in tables by similar characteristics, and the database program maintains the relationships between the tables. For example, the characteristics of a particular financial instrument might be found in one table while it's trading history can be found in another table. These tables can be then be related by the identifier of the instrument. Table based database systems are known as relational databases. Relational database programs are optimized for searching, for reporting selected data from the database, and for writing data to selected data tables.
Communication with commercial databases is typically done via a structured query language (SQL). SQL lines can use variable input parameters, such as the name of a financial instrument, or a date, or range of dates. Many lines of SQL code may be required for a given database operation. Stored procedures are lists of SQL code that allow for input parameters and generate tabular result sets. The stored procedures are generally stored in the database.
By contrast, applications are usually written in high level object oriented languages. Object oriented languages such as J2EE offer very powerful and computationally efficient computing environments for solving business calculations. (The calculations are typically presented to the application developer as a set of rules known as the business model). Object Oriented languages are designed to work with objects. Objects are programming structures of the application that contain both functions and the corresponding data for a given computational task. They are generally focused on solving a particular problem.
An application runs on one or more computers. During “runtime” it typically reads and writes large volumes of information in the form of data. After a particular run, the program needs to save a great deal of information so that the next time it runs, it continues one or more calculations from the previous ending state. Also, some data within objects simply needs to be saved in the database. Persistence refers to the ability of the application to save various conditions of the application and data at the end of a run so that it is available to the application at the beginning of the next run.
Object oriented languages are becoming ever more rich in their ability to interact with other systems and programs such as commercial database programs. They do this by offering a suite of libraries that provide pre-written application programming interfaces (API) for application developers. For example J2EE offers tools to communicate with database programs such as SYBASE. Even with these tools, the Java programmer still must write many lines of JAVA code and then many lines of SQL code (stored procedures) to perform a given database operation. Depending on the complexity of the interaction, it can literally take weeks for a programmer to write all of the needed code for an interaction between the application and the database, as between JAVA and SYBASE. And, because the stored procedures can comprise many lines of very detailed SQL code, there is a very good chance for coding errors. Proof reading such code is difficult and time consuming.
Because the application handles information as part of its objects, and the database handles information as tables, the data structures must be converted for the two programs to communicate with each other. One approach is to provide a system that maps tabular data to objects in a way that is transparent to the programmer writing the application. This system of binding tabular data to objects is called databinding. In databinding, objects can be written that deal only with the information to be exchanged. Similarly, stored procedures can be written to only carry out the corresponding database interactions. The stored procedures are “lightweight” in the sense that they do not perform any business calculations. A method, or framework, to manage data for an application is ideally “encapsulated”. That is, it is isolated from the application's business calculations (the business model).
What is needed is a method that implements a lightweight stored procedure framework whereby the applications programmer solving a business model need only specify a few simple lines of code to communicate with the tabular data in a relational database.